In communication networks which support Session Initiation Protocol (SIP), user equipment devices (UEs) register with the network before they can place or receive calls. When Transmission Control Protocol (TCP) is used as the transport protocol, there are cases where the TCP connection established during the registration process is not used for calls initiated by the UE at a later time. In many cases a UE device establishes a new TCP connection for each call. There are also scenarios, where a session border controller (SBC) failover causes similar behavior thus causing the establishment of a new TCP connection for a new call as TCP connections are not preserved after a SBC failover. After the detection by a UE device that its TCP connection toward the SBC is lost such as for example during a SBC failover event, when the UE device attempts to place a new call it initiates a new TCP connection. This results in the signaling for the new call being sent over the new TCP connection. In such cases, the SBC receives a new call request over a new TCP connection.
While in many cases it is possible that the UE that has been previously authenticated establishes a new TCP connection for placing a new call, still there is no guarantee that a UE attempting to place a call over a new TCP connection is actually a legitimate device that has been previously authenticated. It is possible that an attacker with malicious intent may attempt to place a call over a new TCP connection. Thus there is a need to take steps to ensure that the new TCP connection is indeed initiated by a legitimate user and/or UE rather than an attacker.
In many communications systems, such as for example many systems using SIP based signaling, to authenticate a new TCP connection, the SBC relies on a Registrar challenging the INVITE requests of registered initiators. See for example, Request For Comment 2617 by the Internet Engineering Task Force entitled: “HTTP Authentication: Basic and Digest Access Authentication” which discusses authentication processes. If the authentication process involving this INVITE-Challenge-Response is successful, the SBC concludes that the initiator is who it claims to be. However, not all Registrars challenge INVITE requests. Some Registrars only challenge REGISTER requests and not INVITE requests. In such systems, once the initiator is registered INVITE requests are not challenged.
From the above discussion it should be appreciated that there is a need for methods and apparatus for authenticating a device and/or user attempting to access a service, such as for example, establish a call, over a new TCP connection, and/or for authenticating a new TCP connection/call when the Registrar does not challenge INVITE requests. It should be further appreciated that there is also a need for new methods and apparatus wherein a device such as a session border controller which does not have access or possession of an authentication secret or key used by an authentication entity which normally performs the authentication operations to be able to provide device and/or connection authentication.